Generic Framing Procedure (“GFP”) is an encapsulation technique defined by the International Telecommunication Union standard ITU-T G.7041. GFP provides mapping of traffic from higher-layer packet oriented client signals over a transport network.
In recent years, the bandwidth demand on telecommunications networks has increased dramatically. As a result, 100 Gigabit/second (100 Gbps) class protocols have been defined in IEEE Ethernet and in ITU-T Optical Transport Network. Four hundred Gigabits per second protocols and 1 Terabit per second protocols are expected to be defined in the near future. However, successive generations of CMOS technologies have only been able to reduce feature sizes, allowing for dramatically more gates per unit area, but have not significantly increased the speed of each gate. As the data rate rises according to increasing demand for bandwidth, processing elements must resort to using wider and wider internal data paths to cope with the bandwidth demands.
In a frame-mapped GFP mode, each upper-layer client packet is mapped to a single GFP client frame. A device receiving a stream of GFP data will need to demap the GFP data into the upper-layer packet data. A GFP demapper provides an ingress interface that is a digital constant bit rate (CBR) interface for receiving CBR-type GFP data, and an egress interface that is a digital packet interface for transmitting upper-layer packet data. The following discussion of characteristics of the GFP standard is relevant to the design of a GFP demapper.
In addition to providing GFP client frames, GFP also provides for GFP control frames, which are currently only functionally defined as idle frames. In the remainder of this disclosure, the terms GFP control frame and GFP idle frame will be used interchangeably.
GFP client frames are further divided into GFP client data frames, which carry client data in the payload bytes of the GFP frame, and GFP client management frames, which transport management information in the payload bytes of the GFP frame. Generally, a GFP client frame is comprised of a four-byte core header and a payload area of size ranging from 4 to 65535 bytes. In contrast, a GFP idle frame solely comprises the four-byte core header.
The core header comprises a 16-bit payload length indicator (PLI) field and a 16-bit core header error check (cHEC) field. Therefore, all GFP frames received on a bus include a four-byte core header, which, along with the PLI, can be used to delineate the boundaries of all of the frames. In order to provide a packet-like egress interface, the GFP demapper comprises a GFP framer for delineating the GFP frames received on the CBR-like ingress interface.
Generally, the GFP framer performs GFP frame delineation starting from a HUNT state by parsing an incoming stream of data, byte-by-byte, for a four-byte core header. The framer evaluates the 16-bit cHEC field of the core header, which is a 16-bit CRC code over the 32 bits of the core header. Once a correctly formatted core header is found, the framer looks to the PLI field to determine the expected location of the next core header. The cHEC field of the next core header is then evaluated, and if the core header is correctly formatted, the framer has identified two consecutive core headers. Depending on the application, two consecutive core headers may be enough synchronization for frame delineation. Otherwise, if synchronizing to more consecutive core headers is desired, the framer may repeat the process of determining a next expected core header from the PLI field and evaluating the cHEC field of the next expected core header for as many correctly formatted core headers as required.
If the data stream is incoming on a bus, then the framer performs frame delineation as described above on the data on the bus. However, there may be more than one delineated GFP frame on the bus. In fact, given the four-byte size of GFP idle frames and a data bus of large enough width, there may be a high probability that multiple GFP frames are resident on the data bus at any time. Delineating all of these frames on a bus in a single clock or data cycle becomes increasingly difficult as data paths increase in width.
In order to provide a packet-like egress interface, the GFP demapper also comprises a GFP frame unpacker because a packet interface transmits data bytes from one packet per clock or data cycle on a data bus. Thus, even delineated GFP frames on a data bus require further processing in order to unpack the frames from the data word into packets.
The GFP frame unpacker provides packetized GFP frames to upper-layer protocols. Unpacking logic unpacks the GFP frames into packetized format one at a time from the received data word on the bus. The unpacked GFP frame is attached with SOP and EOP tags. Together, the GFP framer and the GFP unpacker provide GFP frame demapping to upper-layer logic.
As bandwidth demand in a communications system increases, design choices often force the data paths in communications systems to grow increasingly wide. Therefore, an efficient and scalable GFP demapper for wide data bus applications is desirable.